Model merger using an export map

ABSTRACT

In one embodiment, data is exchanged between a modeling application and an external application. A user initiates an export of model data from the modeling application, where the model data is descriptive of a model maintained in the modeling application. An export map is generated that captures an indication of each object in the model at the point in time of export of the model. Model data is passed to the external application. Subsequently, modified model data is received from the external application. The modified model data is compared with the export map to detect external modifications made by the external application. Limited portions of the model in the modeling application are updated to reflect the external modification, while intact portions of the model for which external modifications have not been detected are left intact.

BACKGROUND

1. Technical Field

The present disclosure relates generally to computer-aided engineeringdesign and more specifically to techniques for “round tripping” modeldata between a structural modeling application and an analyticalapplication.

2. Background Information

To better manage the complexities of modern designs, engineers oftenturn to computer-aided engineering design. In computer-aided engineeringdesign, an engineer creates a model that embodies an engineeringproject. The model is typically refined and analyzed, in part, usinganalytical tools. A completed model may be used to generate presentationdocuments (such as plans, elevations and perspectives) andquantification reports (such as quantity reports, schedules, and costestimates), useful in executing the engineering project.

One particular use of computer-aided engineering design is in thedeployment of structural systems for buildings, industrial plants, civilprojects, and the like. An engineer tasked with the design of astructural system may first prepare an initial draft of a design using astructural modeling application. For example, the engineer may turn toan application such as the Bentley Structural™ building informationmodeling (BIM) application, available from Bentley Systems Inc., theRevit® Structure application, available from Autodesk Inc., or anothersimilar software package. A structural modeling application typicallyprovides the engineer with a number of predefined intelligent structuralforms, such as steel girders, concrete beams, timber studs, etc. Using acomputer aided design (CAD)-like interface, the engineer may place,arrange, and configure these structural forms, to design the structuralsystem. Often, the engineer will work initially with physicalrepresentations of the structural forms. That is, he or she maymanipulate physical representations to create a physical model thatapproximates the appearance of a realworld structural system.

As a physical model is often not best suited for structural analysis,optimization, code checking, or other types of in-depth analyticalprocessing, the engineer may next turn to an analytical model. Ananalytical model typically represents a structural system in terms of aseries of equations that may be solved for reactions, rotations, and thelike. Some structural modeling applications generate an analytical modelin a background process as a physical model is being constructed by theengineer. That is, as the engineer places and arranges physicalrepresentations to create a physical model, corresponding analyticalrepresentations may be automatically placed in a parallel analyticalmodel.

While a structural modeling application may offer some native analyticalprocessing functionality, some types of advanced analytical processingare more typically offered by separate analytical applications. Forexample, STAAD® structural engineering software available from ResearchEngineers International offers finite element, linear static, responsespectra, time history, cable, pushover, and non-linear analysis, as wellas other advanced functionality. Similarly, RAM® structural software,available from RAM International, offers a variety of types of advancedanalysis functionality. A number of other commercially availableanalytical applications provide useful functionality.

To utilize the functionality of a separate analytical application, anengineer typically exports the analytical data from the structuralmodeling application to the analytical application. Typically, exportingentails translation from a file format used internal to the structuralmodeling application to a differing file format used by the analyticalapplication. Once the analytical data is exported, it is commonlysubject to repeated rounds of analysis, code checking and/oroptimization within the analytical application. Each of these rounds mayresult in changes to the data, as the structural system is refined andfine tuned. When a “final” set of analytical data is reached (at leastfor this stage of the design process) it typically is imported back intothe structural modeling application. Such importing generally involvesanother translation of file formats, this time from the file format usedinternal to the analytical application to the file format used in thestructural modeling application.

The imported analytical data typically overwrites some, or all, of theversion of the analytical model in the structural modeling application.The physical model is then updated to reflect the changes in theanalytical model. The overall process of export and subsequent import ofanalytical data is commonly referred to as “round tripping.” Such roundtripping may occur repeatedly during the design of a complex structuralsystem, where a design may evolve considerably over time.

However, there are a number of shortcomings with current round trippingtechniques that hinder efficient import and export of data. As discussedabove, when modified analytical data is imported back into a structuralmodeling application, at least some of the analytical model in thestructural modeling application is typically overwritten. Suchoverwriting typically occurs without regard to existing objects in themodel, writing over both portions that have been changed by theanalytical application and that have not is been changed by theanalytical application. This has a number of undesirable implications.

For example, there is typically a danger of introducing errors in thestructural system. Such danger is particularly acute if work continuesin the structural modeling application, while analytical data is beingsubject to analysis and refinement in the analytical application. If anengineer makes changes within the structural modeling application, someof these changes may be lost when overwriting of the analytical modeloccurs. Similarly, overwriting may sometimes inadvertently createduplicates within the models of the structural modeling application.Inadvertent loss or duplication is sometimes quite difficult to detect,absent lengthy manual review and verification.

Such difficulty is typically often compounded by incomplete reporting ofchanges upon import of an analytical model in existing systems. Whilesome existing structural modeling applications may detect and reportsome types of changes during import, other types of changes are commonlynot detected or reported. For example, deletion of structural forms inthe analytical application (hereinafter referred to as “externaldeletes”) are typically not detected or reported. Accordingly, if anengineer desires to know exactly what has been externally deleted, he orshe may have to spend extended time manually reviewing and comparingmodels.

Accordingly, there is a need for improved techniques for round trippingmodel data between a structural modeling application and an analyticalapplication.

SUMMARY

In one embodiment, the shortcomings of the prior art are addressed by anovel round tripping technique, where modifications made in an externalapplication are recognized, reported to a user, and intelligently mergedinto a model based, in part, on an export map. The export map representsa “snapshot” of a model at the time it was exported to, or just after itwas previously imported from, an external application, identifying eachobject that exists in the model at that point in time. Upon subsequentimportation of a modified version of model data, the export map is usedas a basis for comparison to permit improved recognition, reporting andmerging of external modifications.

More specifically, an engineer may create a physical model and ananalytical model of a structural system within a structural modelingapplication. These models may include a plurality of different objects,corresponding to graphics and non-graphics features. Objects areassociated with unique element identifiers (ID). At some point in time,the engineer may choose to export analytical data to a particularanalytical application, for example to perform some type of analysis.Analytical data is translated to a format understood by the analyticalapplication, which may use an independent set of object identifiers,i.e., “external IDs.” At the time of export, an export map is generatedthat may include a list of element IDs and/or a list of external IDs forevery object exported, depending on the capabilities of the analyticalapplication.

The analytical data may be subject to repeated rounds of analysis,testing, and optimization at the analytical application in whichmodifications to the analytical data may be made. After modifications,the modified data may be imported back into the structural modelingapplication. Upon import, a comparison is made between either elementIDs in the modified data and the list if element IDs in the export map,or external IDs in the modified data and the list of external IDs in theexport map, as appropriate. Such comparison may yield an indication ofexternal modifications, including deletions which have previously beendifficult to detect. The external modifications are reported to a user,and may be intelligently merged into the existing analytical model. Thatis, rather than indiscriminately overwriting duplicate objects, existingobjects that have been externally modified are updated to reflect newproperties. The export map is also updated.

Such technique may advantageously prevent the loss or duplication ofmembers within models, even if work continues on the models while datais being modified at the analytical application. Further, suchtechniques may enable more comprehensive reporting of externalmodification, including reporting of external deletes.

BRIEF DESCRIPTION OF THE DRAWINGS

The description below refers to the accompanying drawings, of which:

FIG. 1 is a block diagram of an example computer system in which atleast some of the presently described techniques may be employed;

FIG. 2 is a block diagram of example data structures included in adesign file;

FIG. 3A is an isometric view of an example physical model;

FIG. 3B is an isometric view of a visual representation of an exampleanalytical model of the same structures as shown in FIG. 3A;

FIG. 4 is an abstracted block diagram that illustrates the use ofidentifiers in round tripping of data between a structural modelingapplication and an analytical application;

FIG. 5 is a block diagram of an example export map;

FIG. 6 is a flow diagram of an example export operation of analyticaldata from a structural modeling application to an analyticalapplication;

FIG. 7 is a flow diagram of an example import operation of analyticaldata from an analytical application to a structural modelingapplication; and

FIG. 8 is an example Update Design Results graphical user interface(GUI) for display of detected external modifications.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example computer system 100 in which atleast some of the presently described techniques may be employed. Thecomputer system 100 includes at least one central processing unit (CPU)110 coupled to a host bus 120. The CPU 110 may be any of a variety ofcommercially available processors, such as an Intel x86 processor, anIBM PowerPC processor, a SPARC processor, or another type of processor.A memory 140, such as a Random Access Memory (RAM), is coupled to thehost bus 120 via a memory controller 130. The memory 140 is adapted tostore at least a portion of an operating system 142 while the computersystem 100 is operating. In addition, the memory 140 may store portionsof application software, including portions of a structural modelingapplication 150, and in some cases, a separate (i.e., external)analytical application 155, as discussed in more detail below.

The host bus 120 of the computer system 100 is coupled to aninput/output (I/O) is bus 160, such as a Peripheral ComponentInterconnect (PCI) bus, through a bus controller 165. A video displaysubsystem 170, coupled to a display 175, may be connected to the I/O bus160. The display 175 may show a user interface of the structuralmodeling application 150, and, in some cases, a user interface of theanalytical application 155. Similarly, one or more input devices 178,such as, a keyboard, a mouse, or a touch pad, may allow a user tointerface with the applications 150, 155.

A storage device 180, such as hard disk drive, a compact disk (CD)drive, Digital Video Disc (DVD) drive, or other type of device, may becoupled to the I/O bus 160 and persistently store data, includingcomputer-executable instructions. Such persistently stored data may beloaded to the volatile memory 140 when needed. For example,computer-executable instructions related to the operating system 142,the structural modeling application 150, and, in some cases, theanalytical application 155 may be stored in the storage device 180 untilthey are needed.

The I/O bus 160 may further be coupled to a network controller 190 thatinterfaces with a computer network 195. The computer network 195 mayallow communication between the computer system 100 and other computersystems, for example a remote computer system 198, using any of a numberof well known network protocols. Such network communication may allowcertain remote, distributed and/or parallel computing configurations.

In more detail, the structural modeling application 150 may be abuilding information modeling (BIM) application operating within acommon technology platform 152. Such a common technology platform 152may provide base functionality relating to object management, geometricmodeling, drafting, information and standards management, visualization,drawing and report extraction, as well as other tasks. In theillustrative embodiment, the structural modeling application 150 is theBentley Structural™ BIM application, available from Bentley SystemsInc., and the technology platform 152 is the MicroStation Triforma®technology platform, also available from Bentley Systems Inc. However,the structural modeling application 150 may alternately be anotherapplication, such as the Revit® Structure application available fromAutodesk Inc., or another software application that provides modelingfunctionality. Similarly, the technology platis form 152 may be adifferent technology platform, or may not be employed at all, dependingon the particular implementation.

The structural modeling application 150 may store models of a structuralsystem in a design file 200, or multiple design files. In theillustrative embodiment, the design file 200 is a DGN file formattedaccording to the MicroStation® V8 DGN standard. Such file 200 maintainsa physical model, an analytical model and non-graphics data descriptiveof a structural system. Alternately, the design file 200 may be adifferently formatted file. For example, the design file 200 may be aDWG file, a DXF file or a file formatted according to any of a varietyof other known standards. Further details relating to the organizationof a design file 200, and its use with the presently disclosedtechniques, may be found below.

The analytical application 155 may be a STAAD® structural engineeringapplication available from Research Engineers International, a RAM®structural application available from RAM International, a MIDAS®general-purpose structural analysis application available from MIDASInformation Technology Co., Ltd., a GSA™ structural analysis applicationavailable from Oasys Limited, a RISA® structural analysis applicationavailable from RISA Technologies, Inc., or any of a variety of otheranalytical applications that allow a user to analyze, test, refine, finetune, and/or optimize a system. The analytical application 155 maymaintain data descriptive of a structural system in a data file 158, ormultiple data files, formatted according to a standard employed by theanalytical application 155. For example, the data file 158 may be an RSSfile, a STD file, or a file formatted according to another standard.

A data file 158 used by an analytical application 155 may be generatedby exporting the analytical data from the structural modelingapplication 150. In an export, the design file 200 of the structuralmodeling application 150 is typically translated by a translator (notshown) used with the analytical application 155, and translated modeldata is written to the data file 158. In this manner, an engineer neednot separately create an analytical model within the analyticalapplication 155, but rather may export existing work to establish such amodel. Once analytical data is accessible to the analytical application155, it may be subject to repeated rounds of analysis, code checkingand/or optimization. In each of these rounds, the data may be refinedand fine tuned to address any issues raised. When “final” analyticaldata is reached, it is typically imported back into the structuralmodeling application 150, where it is used to update the analyticalmodel and the physical model maintained therein, as discussed in moredetail below. Thus, in effect, the analytical model is “round tripped”between the two applications.

While FIG. 1 depicts both the structural modeling application 150 andthe analytical applications 155 as resident in the memory 140, forexecution locally on CPU 110, they may instead be resident on differingcomputer systems. For example, in one alternate configuration, theanalytical application 155 may be resident in the memory of, andexecuted on, a remote computer system 198. In such a configuration,exporting and importing of the analytical model may include transmissionof model data over a computer network 195. Accordingly, it should beunderstood that the techniques described herein are not limited toapplication in a single computer system 100, but may also used with avariety of remote, parallel, and/or distributed computing arrangements.

FIG. 2 is a block diagram of example data structures that may beincluded in a design file 200. The design file 200 may include twoprimary types of data structures: graphics objects 210 that may bevisually represented to a user, and non-graphics objects 220 that do nothave a ready visual representation. A graphics object 210 includesphysical object 230, such as linear members 235, solids 240, and walls245, which collectively define a physical model of a structural system.An isometric view 300 of an example physical model is depicted in FIG.3A.

A graphics object 210 also includes analytical objects 250, such aslinear elements 255, 2D plate elements 260, and nodes 265, whichcollectively define a parallel analytical model of the structuraldesign. An isometric view 350 of a visual representation of ananalytical model is depicted in FIG. 3B.

In addition to graphics objects 210, the design file 200 furtherincludes non-graphics objects 220. Non-graphics objects 220 may includeload cases 270 and load combinations 280 that define loads incident onstructural forms. Typically, each object in the design file 200 isassociated with an element identifier (ID) (not shown) used to identifyobjects in the structural modeling application 150. In the illustrativeembodiment, is the element IDs are Microstation® Element IDs, however inalternate implementations they may take on any of a variety of otherforms. The element IDs are typically non-graphic in nature and aregenerally assigned automatically by the system, outside of the controlof a user.

Element IDs may be used in conjunction with a novel export map 500. Asdiscussed in more detail below, the export map 500 is a non-graphicsobject that captures a “snapshot” of a structural model at the timeanalytical data is exported or just after it was previously imported,indicating each object that exists in the model at that point in time.The export map 500 provides a basis for comparison when a modifiedversion of the analytical data is subsequently imported as part of around tripping operation.

In order to understand the operation of the novel export map 500, it ishelpful to consider how identifiers are used in round tripping of databetween a structural modeling application 150 and an analyticalapplication 155. As discussed above, each object in a design file 200 isassociated with an element ID. For example, in reference to FIG. 4, aparticular analytical object 410 is associated with a particular elementID 420. When the analytical model in the design file 200 is exported, atranslator 430 a, 430 b generates corresponding representations 440 a,440 b for use in the analytical application 155 a, 155 b. The translatortypically associates each corresponding representation 440 a, 440 b withan ID 450 a, 450 b used by the analytical application 155 a, 155 b(hereinafter an “external ID”). Such external IDs 450 a, 450 b typicallyfollow an ID system of the analytical application 155, which often hasbeen developed independently from the system used within the structuralmodeling application 150.

The data file 158 a of some analytical applications 155 a is capable ofstoring both external IDs 450 a as well as copies of element IDs 420,thus preserving a record of element IDs 420. For example, STAAD®structural engineering applications allow for such storage of elementIDs. However, the file format of others analytical applications 155 b isonly capable of storing external IDs 450 b, and thus the data file 158 bcontains no indication of element IDs. For example, RAM® structuralapplications typically may only store external IDs.

When analytical data is imported back in to the structural modelingapplication 150, translator 430 a, 430 b accesses the element IDs and/orexternal IDs stored in the data file 158 a, 158 b and uses them inconjunction with the export map 500 of the design file 200 to report andmerge external modifications.

FIG. 5 is a block diagram showing an example export map 500 in greaterdetail. A list of element IDs 510 is configured to store element IDs 510for every object that exists in the design file 200 at the time theanalytical model is exported. Similarly, a list of external IDs 520 isconfigured to store corresponding external IDs 520 for the objects atthe time of export. Finally, corresponding object type data 530indicates object types associated with the element IDs and external IDs,for example, an indication that an ID refer to a linear member, a solid,a wall, etc.

Depending on the capabilities of the analytical application 155, onlycertain of the lists 510, 520 may actually be utilized. For example,when the file format of the data file 158 of the analytical application155 is capable of storing element IDs, only the list of element IDs 510may need to be employed. However, when the file format of the data file158 is incapable of storing element IDs, it may be necessary to use boththe list of element IDs 510 and the list of external IDs 520.

The export map 500 is preferably maintained as a non-graphical object inthe design file 200 of the structural modeling application 150. Whileanalytical data is being refined and modified at the analyticalapplication 155, the export map 500 remains unchanged in the structuralmodeling application, even if work proceeds in the application. That is,should an engineer continue to work within the structural modelingapplication 150, for example by placing or changing structural forms,such changes are not reflected in the export map 500.

When modified analytical data is subsequently imported back into thestructural modeling application 150, the export map 500 may be used as abasis of comparison to determine which portions of the analytical modelhave been changed externally. This is facilitated by comparison ofexternal IDs or element IDs in the data file 158 to the list of externalIDs 520 or the list of element IDs 510 in the export map 500. Asdiscussed below in more detail, external modifications may be readilydetected, reported to a user and intelligently merged into theanalytical model in the structural modeling application 150.

FIG. 6 is a flow diagram of an example export operation of analyticaldata from a structural modeling application 150 to an analyticalapplication 155. At step 610, a user selects an option to initiate anexport of analytical data to a particular analytical application 155,for example by using a graphical user interface. At step 620, atranslator generates a data file 158 from the data according to a fileformat understood by the analytical application 155. Depending on thefile format, either external IDs, or a combination of external IDs andelement IDs are written to data file 158. At step 630, an export map 500is generated and stored as a non-graphics object within the design file200. If the data file 158 is capable of storing element IDs, thetranslator may simply write a list of element IDs 510 and correspondingobject type data 530 to the export map 500. If the data file 158 isincapable of storing element IDs, the translator may write both a listof element IDs 510 and a list of external IDs 520, as well ascorresponding object type data 530, to the export map 500. At step 640,the data file 158 is passed to the analytical application 155 foranalytical processing.

FIG. 7 is a flow diagram of an example import operation of analyticaldata from an analytical application 155 to a structural modelingapplication 150. At step 710, a user selects an option to initiate animport of analytical data, for example using a graphical user interface.At step 720, the data file 158 maintained by the analytical application155 is read by a translator. At step 730, a determination is madewhether there is an existing export map 500 in the design file 200maintained by the structural modeling application 150, which correspondsto the analytical data being imported. If not, progression may proceedto step 790 where the analytical model is updated using conventionaltechniques. If there is an export map 500, execution proceeds to step740 and a comparison is made between IDs maintained in the data file 158and the export map 500. More specifically, if element IDs are stored inthe data file 158, these element IDs are compared with the list ofelement IDs 510 maintained in the export map 500. Otherwise, if elementIDs are not stored in the data file 158, external IDs in the data file158 are compared to the external IDs stored in the list of external IDs520 maintained in the export map 500. Since the export map 500represents a “snapshot” of the objects in the analytical model at thetime of export, or just after a prior import, any more recent changes tothe data file 200, for example due to continuing work in the structuralmodeling application 150, are not considered. As such, externalmodification are not confused with the internal modifications.

At step 750, the external modifications are reported to a user, forexample via an “Update Design Results” GUI 800. In reference to FIG. 8,the Update Design Results GUI 800 may be organized into a plurality ofobject type tabs, for example, a tab for linear members 810, a tab forsolids 820, a tab for walls 830, a tab for load cases 840, and a tab forload combinations 850. Any modifications to the corresponding types ofobjects are displayed in the appropriate tabs. Various information aboutthe modifications may be shown. For example, for a linear member afamily name 860, a part 865, a current section 870, a new section 875, achange 880, a file 885, and an ID 890 may be displayed to the user. Inparticular, the change 880 may indicate whether the modification is anaddition, a change, or a deletion. The Update Design Results GUI 800 mayallow a user to select that the external modifications are to beapplied, for example by clicking an update button 895 or manipulatinganother user interface element. Alternately, the user may deny allexternal modifications, for example by clicking a cancel button 898 ormanipulating some other user interface element.

Assuming the user selects to accept the external modifications,execution proceeds to step 760. At step 760, the external modificationsare intelligently merged into the design file 200. Rather thanindiscriminately overwriting duplicate objects in the design file 200,only existing objects that have been externally modified, as indicatedby the export map 500 are updated. Such updating may involve changingthe properties of an object, for example changing the endpoints of alinear member, adding an opening in a wall, modifying the equation of aload combination, or other modifications of existing object data.Updating may also involve adding new objects to the design file 200 ordeleting particular objects from the design file 200. However, objectsin the design file 200 that are not subject to external modification areleft intact, to preserve any internal modifications.

At step 770, an export map 500 is written to reflect the changes to theanalytical model in the design file 200. By capturing these changes inthe export map 500, the techniques described herein may be applied tosequential imports of data from the analytical application 155.

While the above description discusses various embodiments of the presentdisclosure, it should be apparent that a number of modifications and/oradditions may be made without departing from the disclosure's intendedspirit and scope.

For example, while the specific embodiments discussed above involveround tripping of data between a structural modeling application 150 andan analytical application 155, the techniques disclosed herein may alsobe applicable to other types of applications. For example, the teachingsmay alternately be used with any of a variety of types of modelingapplications and external applications, including architectural modelingapplications, mechanical systems engineering applications, electricalsystems engineering applications, site design applications, buildingoperations and management applications, airport design applications,general-purpose CAD applications, graphics design applications,mathematical analysis applications, graphical programming applications,visualization applications, technical computing environments, or any ofa variety of other types of applications.

Further, the above described techniques may be implemented in software,in hardware, or a combination thereof. A software implementation mayinclude computer-executable instructions embodied in a computer-readablemedium. A hardware implementation may include processors, memories,programmable logic circuits, application specific integrated circuits,and/or other types of hardware components. Further, a combinedsoftware/hardware implementation may include both computer-executableinstructions embodied in a computer-readable medium, as well as one ormore hardware components.

Accordingly, it should be understood that the above descriptions aremeant to be taken only by way of example.

1. A method for exchanging data between a modeling application and anexternal application executing on one or more computer systems having aprocessor and a memory, comprising: initiating an export of model datafrom the modeling application executing on the one or more computersystems, the model data descriptive of a model maintained in themodeling application; generating an export map that captures anindication of each object in the model at a point in time of export ofthe model; passing the model data to the external application executingon the one or more computer systems; receiving modified model data fromthe external application; comparing the modified model data with theexport map to detect external modifications made by the externalapplication; and updating limited portions of the model in the modelingapplication to reflect the external modifications, while leaving intactportions of the model for which external modifications have not beendetected.
 2. The method of claim 1 further comprising: reporting theexternal modifications to a user; and presenting a user interfaceelement to the user that when manipulated causes the model to be updatedto reflect the external modifications.
 3. The method of claim 1 whereinthe external modifications include one or more external deletions, andthe step of updating further comprises: deleting one or more portions ofthe model to reflect the one or more external deletions.
 4. The methodof claim 1 wherein the modeling application is a structural modelapplication and the model is an analytical model of a structural system.5. The method of claim 4 wherein the external application is a separateanalytical application operable to analyze the structural system.
 6. Themethod of claim 1 wherein each of a plurality of objects in the modelmaintained in the modeling application is associated with an elementidentifier (ID), and the step of generating comprises writing a list ofelement IDs into the export map for each object in the model at thepoint in time of export, and the step of comparing comprises comparing aplurality of element IDs in the modified model data with the list ofelement IDs in the export map.
 7. The method of claim 1 wherein each ofa plurality of objects in the model maintained in the modelingapplication is associated with an element identifier (ID), the step ofinitiating comprises translating each element ID to an external ID usedby the external application, and the step of generating compriseswriting a list of external IDs into the export map for each object inthe model at the point in time of export, and the step of comparingcomprises comparing a plurality of external IDs in the modified modeldata with the list of external IDs in the export map.
 8. The method ofclaim 1 further comprising: subsequent to the step of passing, modifyingthe model internal to the modeling application; and wherein the step ofupdating preserves the modifications made internal to the modelingapplication while the model data is at the external application.
 9. Themethod of claim 1 wherein the step of generating an export mapcomprises: writing the export map as a non-graphics object of a designfile.
 10. The method of claim 9 wherein the design file is a DGN file.11. The method of claim 1 further comprising: writing an update map thatcaptures an indication of each object in the model after the model isupdated.
 12. A non-transitory computer-readable medium containingexecutable program instructions for exchanging data between a modelingapplication and an external application, the executable programinstructions operable to: initiate an export of model data from amodeling application, the model data descriptive of a model maintainedin the modeling application; generate an export map that captures anindication of each object in the model at a point in time of export ofthe model; pass the model data to an external application; receivemodified model data from the external application; compare the modifiedmodel data with the export map to detect external modifications made bythe external application; and update limited portions of the model inthe modeling application to reflect the external modifications, whileleaving intact portions of the model for which external modificationshave not been detected.
 13. The non-transitory computer-readable mediumof claim 12, further comprising executable program instructions operableto: report the external modifications to a user; and presenting a userinterface element to the user that when manipulated causes the model tobe updated to reflect the external modifications.
 14. The non-transitorycomputer-readable medium of claim 12 wherein the external modificationsinclude one or more external deletions, and the executable programinstructions operable to update comprise executable program instructionsoperable to: delete one or more portions of the model to reflect the oneor more external deletions.
 15. The non-transitory computer-readablemedium of claim 12 wherein the modeling application is a structuralmodel application and the model is an analytical model of a structuralsystem.
 16. The non-transitory computer-readable medium of claim 12wherein each of a plurality of objects in the model maintained in themodeling application is associated with an element identifier (ID), andthe executable program instructions operable to generate compriseexecutable program instructions operable to write a list of element IDsin the export map for each object in the model at the point in time ofexport, and the executable program instructions operable to comparecomprise executable program instructions operable to compare a pluralityof element IDs in the modified model data with the list of element IDsin the export map.
 17. The non-transitory computer-readable medium ofclaim 12 wherein each of a plurality of objects in the model maintainedin the modeling application is associated with an element identifier(ID), and the executable program instructions operable to initiatecomprise executable program instructions operable to translate eachelement ID to an external ID used by the external application, and theexecutable program instructions operable to generate comprise executableprogram instructions operable to write a list of external IDs in theexport map for each object in the model at the point in time of export,and the executable program instructions operable to compare compriseexecutable program instructions operable to compare a plurality ofexternal IDs in the modified model data with the list of external IDs inthe export map.
 18. The non-transitory computer-readable medium of claim12, further comprising executable program instructions operable to:modify the model internal to the modeling application; wherein theexecutable program instructions operable to update preserve themodifications made internal to the modeling application while the modeldata is at the external application.
 19. The non-transitorycomputer-readable medium of claim 12, wherein the executable programinstructions operable to generate comprise executable programinstructions operable to: write the export map as a non-graphics objectof a design file.
 20. The non-transitory computer-readable medium ofclaim 12 further comprising executable program instructions operable to:write an update map that captures an indication of each object in themodel after the model is updated.
 21. A computer system, comprising: aprocessor; and a memory configured to store software for execution onthe processor, the software including a modeling application configuredto initiate an export of model data, the model data descriptive of amodel maintained in the modeling application, and to generate an exportmap that captures an indication of each object in the model at a pointin time of export of the model, a translator configured to translate themodel data, and an external application configured to receive the modeldata, modify the model data and return modified model data to themodeling application, wherein the modeling application is furtherconfigured to compare the modified model data with the export map todetect external modifications made by the external application and toupdate limited portions of the model in the is modeling application toreflect the external modifications, while leaving intact portions of themodel for which external modifications have not been detected.